\documentclass[11pt,a4paper]{article}

\usepackage{ctex}
\usepackage{tikz}
\usetikzlibrary{mindmap}
\usetikzlibrary{shapes.geometric, positioning}
\usetikzlibrary{shapes.geometric, arrows.meta}

% 引入 fancyhdr 宏包 ,使用页眉页脚
\usepackage{fancyhdr}

% 以上代码首先引入了 fancyhdr 宏包，然后清除了默认的页眉和页脚内容。接着，分别设置了左右页的页眉和页脚内容，以及页眉和页脚线的宽度。注意，\leftmark 和 \rightmark 在 LaTeX 中并不自动填充章节或小节标题，你需要使用 \chapter 和 \section 等命令组织文档结构，这些命令会更新对应的标签供页眉引用。另外，如果你不需要页眉线或页脚线，可以将对应的线宽设置为 0pt。在实践中，你可能还需要根据文档类型、要求和个人喜好进行更多定制。

% 初始化页眉和页脚样式
\pagestyle{fancy} % 更改为 fancy 样式，清除默认样式
\fancyhf{} % 清空当前的页眉和页脚内容
% 设置页眉
% R 表示右页（odd pages），L 表示左页（even pages），E 和 O 分别是针对奇偶页的缩写
% \leftmark 通常用于显示章节标题，\rightmark 用于显示小节标题，但需要手动定义或启用相关宏包
\lhead{\leftmark} % 左页（偶数页）页眉放章节标题
\rhead{\rightmark} % 右页（奇数页）页眉放小节标题
% \chead{文章题目} % 中间页眉放置文章标题

% 设置页脚
% 页脚通常放置页码和其他信息
\lfoot{}
\rfoot{\thepage}
\cfoot{} % 中间页脚放置页码

% 控制页眉和页脚的装饰线
\renewcommand{\headrulewidth}{0.5mm} % 设置页眉线下宽度
\renewcommand{\footrulewidth}{0.1mm} % 设置页脚线下宽度

% 无序列表的圆点样式
\renewcommand{\labelitemi}{*}


% 自定义字体的
\newcommand{\myCenteredText}[1]{\begin{center}\large #1\end{center}}

\newcommand{\dependencyInjection}{
	\begin{itemize}
		\item  构造器注入
		\item  setter 注入
		\item 父类继承注入
	\end{itemize}
}

\tikzset{
	server/.style={
		rectangle,
		draw,
		fill=blue!20,
		text width=3em,
		text centered,
		minimum height=2em,
		font=\sffamily
	},
	arrow/.style={
		-Stealth,
		thick,
		shorten >=1pt,
		shorten <=1pt
	}
}

% 作者和标题信息
\title{设计模式-个人版}
\author{张毅}
\date{2024年3月25日}
%\date{\today}
\begin{document}

	\maketitle

	
	\begin{table}[htbp]
		\caption{版本更新说明}
		\label{tab:another_table}
		\centering
		\begin{tabular}{|c|c|c|}
			\hline
			更新人 & 时间 & 更新说明 \\ 
			\hline
			张毅 & 2024年3月25日 & 23种模式初始化说明 \\
			\hline
		\end{tabular}
	\end{table}
	

	
	\newpage
	
	\myCenteredText{序言部分}
	 面向对象的系统中,功能复用的两种常用技术是类继承和对象组合
	 \begin{enumerate}
	 	\item 白箱复用: 类继承允许你根据其他类的实现来定义一个新的实现,但是继承实现存在一些不足之处的
	 	\begin{enumerate}
	 		\item 因为继承在编译的时候就制定了 ,是静态的,所以无法在运行时改变从父类继承的实现
	 		\item 更糟的是,父类通常至少定义了部分子类的具体表示,对子类揭示了其父类的实现细节,所以继承常被认为破坏了封装性
	 		\item 子类中的实现与它的父类有如此紧密的依赖关系,以至于父类实现中的任何变化必然会导致子类发生的变化
	 		
	 		\item 只根据抽象类中的定义的接口来操作对象有以下的两个好处
	 		\begin{enumerate}
	 			\item 客户无须知道他们使用对象的特定类型,只需要知道对象有客户期望的接口
	 			\item 客户无须知道他们使用的对象时用什么类来实现的,只需要知道定义接口的抽象类
	 		\end{enumerate}
	 	\end{enumerate}
	 	\item 黑箱复用: 对象的组合是类继承之外的另一种复用的选择,新的更复杂的功能可以通过组装或组合对象来获得, 对象组合要求被组合的对象具有良好定义的接口
		\begin{enumerate}
			\item 如创建型模式\ref{label:createModel},通过抽象对象的创建过程,这些模式提供不同的方式以在实例化时建立接口和透明的链接,创建型模式确保你的系统是采用针对接口的方式,而不是针对实现的方式而书写的
		\end{enumerate}
	 \end{enumerate}
	
	\section{7大设计原则}
	高内聚,低耦合,可读性,可扩展,可用性,可复用
	\subsection{职责单一}
	 一个类只负责 单一的职责,如订单类,用户类,用户角色类 \dependencyInjection
	\subsection{接口隔离}
	实现类所实现的接口应该是在最小的范围内,接口中不会拥有额外的实现(程序中不使用的实现),如果有必要是需要做接口的隔离拆分的
	\subsection{依赖倒转原则}
	底层代码应该依赖抽象,不应该依赖于实现
	
	\subsection{里氏替换}
	
	抽象类中已有的实现,子类中应该尽可能的避免其被重写,而导致多态的产生, 会发生不可预见性的问题
	
	这种类型的问题: 目前的解决方案是使用 final 关键字标识 抽象类中的方法,限定子类无法重写这部分的方法
	
	\subsection{迪米特法则}
	迪米特法则是尽可能的避免类之间的耦合关系, 因为类与类之间的联系是不可避免的,由于面向对象的特性
	保留类的最小知识的原则,只能存在直接朋友(直接友元)
	
	\textbf{直接友元的分类}
	\begin{enumerate}
		\item 类的成员
		\item 函数的形参
		\item 函数的返回值
	\end{enumerate}
	
	其他情况一律都属于间接友元, 函数中途产生的局部变量也属于间接友元,
	
	\textbf{间接友元的分类}
	\begin{enumerate}
		\item  函数操作,中途产生的局部变量
		\item 等
	\end{enumerate}
	
	 以上的间接友元的就需要通过注入的方式来处理,抽取为私有成员,通过如下的方式进行注入调用
	\dependencyInjection
	
	\subsection{开闭原则}
	  对扩展是开放的,对修改是关闭的: 当新增功能的时候,选择新建类扩展的方式实现,而不是修改现有的实现
	
	
	\subsection{合成复用原则}
	保留着最小单位的复用, 如果可以应该尽量的使用聚合/合成的方式, 避免使用继承的方式来进行复用
	\newpage
	\part{创建型设计模式}\label{label:createModel}
	
	说明: 创建new 初始化,
	
	\section{单例模式:Instance}
	
	定义:单例模式（Singleton Pattern）是一种非常基础且重要的设计模式，主要用于保证在一个JVM（Java虚拟机）中，对于某一特定类而言，无论何时何地，都只存在一个唯一的实例。这种模式常用于那些需要全局共享同一份资源并且只允许创建一次的场景。
	
	单例模式的核心特点：
	\begin{enumerate}
		\item 	唯一性：确保一个类在整个系统生命周期内只创建一个实例。
		\item   全局访问：提供一个全局访问点，使得该唯一实例可以被任何需要它的客户端轻松访问。
		\item   构造器私有
		\item 	静态私有的成员变量,当前类实例instance
		\item 	静态方法getInstance()
		\item   volatile 关键字的单例,可以禁止指令重排
	\end{enumerate}
	
	
	\newpage
	\subsection{静态式单例}
	静态内部类式单例,实质就是类的内部还有一个静态类,当这个类加载的时候,内部的静态类不会出现任何的加载,只有在使用的时候才会触发,
	
	
	\subsubsection{静态式单单例diagram实例}
	\includegraphics[width=1.0\textwidth]{createModel/instance/staticSingleton.pdf}
	\newpage
	\subsection{饿汉式单例}
	\begin{enumerate}
		\item 静态代码块的方式进行初始化,在类加载的时候进行初始化
		\item 静态成员变量直接初始化,在类加载的时候进行初始化
	\end{enumerate}
	
	\subsubsection{饿汉式单例diagram实例}
	\includegraphics[width=1.0\textwidth]{createModel/instance/hungrySingleton.pdf}
	\newpage
	\subsection{懒汉式单例}
	\begin{enumerate}
		\item 不加锁的时候,在多线程的环境下出现多次实例化,无法保证该实例的单例
		\item 加synchronized 关键字的时候,多线程情况下可以保证单例,但是无论是否存在这个单例对象,多次初始化的时候效率低下,
		\item 双重检查锁机制,判空-synchronized当前类-判空; 多线程下推荐使用
		\item 在双重检查锁机制下,再新增一个 volatile 关键字,可以禁止指令重排现象,
	\end{enumerate}
	
	\subsubsection{懒汉式单例diagram实例}
	\includegraphics[width=1.0\textwidth]{createModel/instance/LazySingleton.pdf}
	\newpage
	\subsection{枚举式单例}


	
	\newpage
	\section{工厂模式-factory}
	工厂模式的优势:
	
	\begin{itemize}
		\item 降低耦合度：客户端代码不需要知道具体产品的创建细节，只需要知道如何与产品接口交互。
		\item 易于扩展：当需要增加新的产品类型时，只需新增一个实现产品接口的类和相应的工厂子类即可，原有代码几乎不需要修改。
		\item 控制框架：在复杂的应用场景中，工厂模式能够方便地控制对象的创建过程，比如在依赖注入框架中，工厂常被用来创建并初始化对象。
	\end{itemize}
	
	\subsection{简单工厂模式-Simple Factory}
	这是最简单形式的工厂模式，它定义了一个静态方法，接收一些参数并返回一个相应的产品对象。简单工厂不属于GoF（Gang of Four）所定义的23种设计模式之一，但它常常被认为是工厂模式的一个雏形。
	
	\includegraphics[width=1.0\textwidth]{createModel/factoryModel/simple-factory.pdf}
	
	\newpage
	\subsection{工厂方法模式-Factory Method}
	在工厂方法模式中，父类中定义一个创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
	
	\includegraphics[width=1.0\textwidth]{createModel/factoryModel/factory-method.pdf}
	\newpage
	\subsection{抽象工厂模式-Factory Method}
	抽象工厂模式提供一个接口，用于创建相关或依赖对象家族的一系列对象，而无需指定具体类。每个具体工厂都能创建一系列相关的产品对象
	
		\includegraphics[width=1.0\textwidth]{createModel/factoryModel/abstract-factory.pdf}
	\newpage
	\section{建造者模式-builder}
	也可以适用于实体类的装换,本质是面向接口编程而不是面向实现编程
	
	定义:建造者模式（Builder Pattern）是一种创建型设计模式，它主要用于解决复杂对象的创建过程，并且让这个过程更加可控和灵活。在建造者模式中，一个复杂的对象会被拆解成一系列可配置的部件或属性，然后通过一个独立的构建器（Builder）对象逐步构造这些部件，最后生成一个完整的复合对象。
	
	建造者模式的主要角色包括：
	
	\begin{enumerate}
		\item 抽象建造者（Abstract Builder）: 定义创建产品对象的各个部分的接口，并声明一个返回最终产品的方法（通常是build()方法）。
		\item 具体建造者（Concrete Builder）: 实现抽象建造者的接口，负责具体的构造和装配过程，生成最终的产品。
		\item 指导者（Director）: 负责安排建造者对象的构建顺序，协调各部件的建造过程。可选角色，不是必须的，有些实现中可能省略。
		\item 产品（Product）: 是被构建的复杂对象，包含多个组成部件。
	\end{enumerate}
	
	建造者模式的主要优点有
	
	\begin{itemize}
		\item 封装性好，将复杂对象的创建过程与使用过程分离，使用者无需关注对象的内部构造细节。
		\item 支持细粒度的控制，可以根据不同场景创建不同表现形式的产品。
		\item 便于扩展和维护，增加新的产品种类时只需新增一个具体建造者类，原有代码无需改动。

	\end{itemize}
		建造者模式的应用场景：
	\begin{itemize}
		\item 	当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
		\item 	当构造过程必须允许被构造的对象有不同的表示时。
		
	\end{itemize}
	
	\newpage
	\subsection{代码示例}
	\subsubsection{有指挥者的建造者}
	\includegraphics[width=1.0\textwidth]{createModel/buildModel/has-director-Builder.pdf}
		\subsubsection{没有指挥者的建造者}
	\includegraphics[width=1.0\textwidth]{createModel/buildModel/no-director-Build.pdf}
 
 	\subsubsection{jdk中的StringBuilder}
 	\includegraphics[width=1.0\textwidth]{createModel/buildModel/StringBuilder.pdf}
 	
 	\newpage
 	\subsection{其他说明}
 	\subsubsection{建造者模式和Builder注解}
 	@Builder注解和传统的建造者模式虽然都涉及到对象的构建，但它们之间存在一些区别：
 	
 	传统建造者模式：
 	
 	\begin{enumerate}
 		\item 是一种设计模式，源自GoF的设计模式书籍，旨在将对象的创建步骤分离，以便可以有不同的方式组合这些步骤来创建不同的对象表示。
 		\item 建造者模式通常包括一个构建者类，一个指导类（Director），以及一个产品类。构建者类包含构建对象的步骤，指导类负责协调这些步骤，而产品类是最终构建的对象。
 		\item 这种模式提供了高度的灵活性，可以在不修改现有代码的情况下，改变构建过程或创建新的表示。
 	\end{enumerate}
 	
 	Lombok的@Builder注解：
 	\begin{enumerate}
 		\item 是一个代码生成库Lombok的一部分，它简化了Java代码，自动为一个类生成构建者模式的实现。
 		当在类上使用@Builder注解时，Lombok会在编译时自动生成一个内部静态类
 		\item 通常是$ClassName_Builder$），这个类包含了设置各个属性的方法，以及一个构建目标对象的方法。
 		\item 使用@Builder可以避免手动编写大量的构造函数和链式方法，使代码更加简洁和易于维护。
 		\item 它提供了链式API，允许在一行代码中完成对象的构建，如$Product product = Product.builder().food("Fries").drink("Coke").build();$
 		
 	\end{enumerate}
 	总结来说，@Builder注解是建造者模式的一种便捷实现，它通过自动化代码生成简化了传统的建造者模式的实现。传统建造者模式需要手动编写更多的代码，但提供了更大的灵活性和控制权。而@Builder注解则是一种快速构建简单建造者模式的工具，适用于不需要高度定制构建流程的情况。
 	
 	\subsubsection{建造者模式和convert接口的区别}
 	建造者模式（Builder Pattern）
 	
 	\begin{enumerate}
 		\item 目的：主要用于复杂对象的创建过程，将创建过程和表示分离，使得相同的创建过程能够创建不同的表示。它关注的是对象的逐步构建过程，尤其是当对象的构造过程很复杂，包含多个可选步骤或参数时。
 		\item 结构：包括产品（Product）、抽象建造者（Builder）、具体建造者（ConcreteBuilder）和指挥者（Director）四个角色。产品是被构建的复杂对象；抽象建造者定义了创建产品的接口；具体建造者实现这些接口，负责具体构建步骤；指挥者负责调用具体建造者的构建方法来创建产品。
 		\item 应用场景：当一个类的构造函数有很多参数，或者某些参数是可选的，且不想使用大量的重载构造函数时；当构造过程需要遵循一定的顺序或逻辑时。
 	\end{enumerate}
 	
 	转换接口（Converter Interface）
 	\begin{enumerate}
 		\item 目的：主要解决数据类型的转换问题，即将一种数据类型转换为另一种数据类型。它关注的是数据结构或表示形式之间的转换逻辑。
 		\item 结构：通常定义一个接口，其中包含一个或多个转换方法，如convert(sourceType targetType)。然后，针对每一对需要转换的数据类型，实现这个接口的具体类。
 		\item 应用场景：在需要将数据从一种格式转换为另一种格式时，如从DTO（Data Transfer Object）转换为Entity，或者数据库记录转换为视图模型；在不同模块间传递数据，但模块间数据格式不一致时。
 		
 	\end{enumerate}
 	区别总结
 	\begin{itemize}
 		\item  	目的不同：建造者模式关注于对象的创建过程，而转换接口关注于数据类型的转换。
 		\item  	结构不同：建造者模式包含多个角色，强调构建步骤的组织和管理；转换接口则相对简单，主要是一个转换逻辑的定义和实现。
 		\item  	应用场景不同：建造者模式适用于复杂的对象构建场景；转换接口适用于数据格式或类型的转换场景。
 	\end{itemize}
 	
 	\subsubsection{建造者模式和beanUtils的区别}
 	建造者模式
 	
 	\begin{enumerate}
 		\item 目的：建造者模式主要用于复杂对象的创建，它将对象的构造过程与表示分离，使得构建过程可以更加清晰，更易于控制和扩展。这允许用户通过一步步地指定组件来创建对象，而不必知道内部的具体构造细节。
 		\item 应用场景：当一个类有多个必须的或可选的参数，且这些参数的组合可以产生不同的对象行为或表现时，建造者模式非常有用。它有助于避免过多的构造函数重载和Telescoping Constructor Anti-Pattern（望远镜构造器反模式）。
 		\item 核心组件：包括产品（Product）、建造者（Builder）、具体建造者（Concrete Builder）和指挥者（Director）等角色。
 	\end{enumerate}
 	
 	Apache BeanUtils
 	
 	\begin{enumerate}
 		\item 目的：BeanUtils是Apache Commons库中的一个工具类，主要用于JavaBean之间的属性复制，即快速方便地将一个对象的属性值复制到另一个对象的相应属性上，常用于减少重复代码，提高开发效率。
 		\item 应用场景：当你需要将一个对象的数据转移到另一个具有相同或相似属性的对象时，或者需要处理表单提交到JavaBean的场景，BeanUtils就非常适用。它还提供了类型转换、属性操作等便利功能。
 		\item 核心功能：主要包含属性复制（copyProperties）、属性获取和设置（getProperty, setProperty）等方法，支持忽略空值或未找到的属性等功能。
 	\end{enumerate}
 	
 	总结
 	
 	\begin{itemize}
 		\item  本质区别：建造者模式是一种设计模式，关注于对象的创建过程和结构；而BeanUtils是一个实用工具类，关注于简化已有对象之间的数据传输。
 		\item  使用场景：建造者模式适用于设计复杂对象的构建流程，强调灵活性和扩展性；BeanUtils则更多用于简化日常开发中对象属性的复制工作，提高开发效率。
 		\item  关注点：建造者模式侧重于构建逻辑，而BeanUtils侧重于数据操作的便捷性。
 	\end{itemize}
 	
 	
 	\newpage
 	\section{原型模式-prototype}
 	原型模式（Prototype Pattern）是一种创建型设计模式，它允许我们通过复制现有对象（即原型）来创建新对象，而不是通过直接新建的方式来创建对象。这样做的好处是可以简化对象的创建过程，特别是当创建新对象的成本较大时，原型模式能显著提高效率。
 	
 	在原型模式中，原型对象实现了克隆自身的操作（即“深拷贝”或“浅拷贝”）。当需要创建一个新的对象时，我们可以直接复制一个现有的原型对象，然后对其进行必要的修改，而不是从零开始初始化所有的属性和状态。
 	
 	原型模式的缺陷是每一个Property的子类都必须实现clone操作，这可能很困难，例如当所考虑的类已经存在时，就难以新增clone操作，当内部包括一些不支持拷贝或有循环引用的对象时，实现克隆可能会很困难。
 	
 	还有一种实现原型模式的方式是使用序列化和反序列化的方式(这种方式还是比较推荐的,因为再怎么复杂的实体,都可以只修改这一个类的方式,来进行拷贝)
 	
 	
 	
 	\subsection{实现}
 	
 	\begin{enumerate}
 		\item 使用一个原型管理器
 		\item 实现克隆操作
 		\item 初始化克隆对象
 	\end{enumerate}
 	\subsection{代码示例}
 	\subsubsection{用户信息拷贝}
 	
 	\includegraphics[width=1.0\textwidth]{createModel/prototypeModel/prototype-user.pdf}
 	
 	
 	\newpage
 	\subsection{其他说明}
 	\subsubsection{Beanutils和原型模式的区别}
 	BeanUtils 和原型模式（PrototypePattern）在软件开发中服务于不同的目的，它们之间存在明显的区别：
 	
 	\textbf{BeanUtils}
 	\begin{enumerate}
 		\item 目的与功能：BeanUtils 是一个工具类库，常见于 Java 开发中，尤其是 Apache Commons BeanUtils 库中的一个组件。它的主要目的是简化 JavaBean 对象的操作，如属性的读取、设置、复制等。BeanUtils 提供了一系列静态方法，帮助开发者方便地在 Java 对象之间复制属性值，执行类型转换，减少样板代码。
 		\item 应用场景：常用于表单数据绑定、对象转换、数据传输对象（DTO）与实体类之间的属性复制等场景。例如，从 HTTP 请求参数映射到 Java 对象，或者在业务层之间传递数据时，快速复制对象的属性。
 		\item 实现方式：通过反射机制实现，允许在运行时动态地访问和修改对象的属性。
 	\end{enumerate}
 	
 	\textbf{原型模式}
 	
 	\begin{enumerate}
 		\item  	目的与功能：原型模式是一种创建型设计模式，其核心思想是通过复制现有的实例来创建新的对象，而不是通过 new 操作新建对象。这种模式适用于创建新对象的成本较高或者创建过程复杂的情况，通过克隆现有对象可以简化对象的创建过程。
 		\item  	应用场景：适用于需要大量相似对象的场景，或者创建对象的开销较大时。例如，游戏中的角色克隆、文档编辑软件中的模板复制、深度学习中的模型初始化等。
 		\item  	实现方式：在 Java 中，原型模式通常通过实现 Cloneable 接口并重写 clone() 方法来实现。clone() 方法返回对象的一个浅拷贝，如果需要深拷贝（即复制对象的所有引用对象），则需要额外处理。
 	\end{enumerate}
 
 	\textbf{总结}
 	
 	\begin{itemize}
 		\item 本质差异：BeanUtils 是一个实用工具库，专注于简化JavaBean的操作，提高开发效率；而原型模式是一种设计模式，关注如何高效地创建和管理对象的副本。
 		\item 使用场景：BeanUtils 适用于日常开发中的对象属性操作，如数据绑定和复制；原型模式则在需要高效创建复杂或成本较高的对象副本时发挥作用。
 		\item 实现机制：两者都利用了反射机制，但BeanUtils更偏向于属性的读写操作，原型模式侧重于对象的复制创建。
 	\end{itemize}

 	\newpage
	\part{结构型设计模式-Structure}
	
	代码之间的结构
	
 	\section{适配器模式-adapter}
 	适配器模式（Adapter Pattern）是一种结构型设计模式，主要用于解决接口不兼容的问题，使原本由于接口不一致而无法一起工作的类能够协同工作。这种模式的核心思想是通过增加一个适配器类，将源接口转换为目标接口，从而使客户端能够通过目标接口与适配器交互，达到间接调用源类方法的目的。
 	具体来说：
 	
 	\begin{enumerate}
 		\item 问题场景：当两个现有的类之间由于接口不匹配而无法彼此合作时，或者需要使用第三方库中的类，但是该类的接口不符合项目的需求时，可以使用适配器模式。
 		\item  角色构成：
 		\begin{itemize}
 			\item 目标接口（Target）：定义客户端期望的接口，它可以是一个抽象类或接口。
 			\item 源接口（Adaptee）：需要被适配的已有接口，即待适配的类所提供的接口。
 			\item 适配器（Adapter）：实现目标接口，同时持有源接口的一个实例（或引用），并在目标接口的方法中调用源接口的方法，完成适配过程。
 		\end{itemize}
 		
 		\item 应用：适配器模式广泛应用于软件开发中，尤其是在集成遗留系统、与其他系统进行对接、以及统一接口风格等方面非常有用。例如在GUI编程中，将某个控件的功能适配成符合特定框架要求的形式就是一个典型的适配器应用场景。
 	\end{enumerate}
 	
 	\
 	
 	\newpage
 	\subsection{代码示例}
 	
 	\subsubsection{适配器组合-推荐}
	\includegraphics[width=1.0\textwidth]{structModel/adapterModel/AdapterModeCombination.pdf} 	
	
 	\subsubsection{适配器继承-不建议}
	\includegraphics[width=1.0\textwidth]{structModel/adapterModel/AdapterModel-Extends.pdf} 	
 	
 	\newpage
 	\section{桥接模式-bridge}
 	桥接模式（Bridge Pattern）是一种结构型设计模式，其主要目的是将抽象部分与实现部分分离，使它们都可以独立变化。桥接模式通过创建一个抽象层次和实现层次，并让它们通过组合的方式连接在一起，从而降低了耦合度，提高了系统的灵活性。
 	
 	核心概念与角色：
 	
 	\begin{enumerate}
 		\item 抽象化（Abstraction）：定义抽象接口，维护对实现化对象的引用，它主要负责定义与实现化角色之间的接口。
 		\item 扩展抽象化（Refined Abstraction）：是抽象化的子类，它实现了抽象化角色中的一些细节，同时可以调用实现化角色的方法。
 		\item 实现化接口（Implementor）：定义实现化角色的接口，供实现化角色的具体实现类继承。
 		\item 具体实现化（Concrete Implementor）：实现了实现化接口，提供了具体的实现方法。
 	\end{enumerate}
 	
	\begin{tikzpicture}[level distance=8mm,
		level 1/.style={sibling distance=50mm,nodes={fill=red!45}},
		level 2/.style={sibling distance=30mm,nodes={fill=red!45}},
		level 3/.style={sibling distance=5mm,nodes={fill=red!45}},
		]
		
		\node {手机}
		child {node {直立式}
			child {node {华为}}
			child {node {小米}}
			child {node {Vivo}}
		}
		child {node {直折叠式}
			child {node {华为}}
			child {node {小米}}
			child {node {Vivo}}
		}
		child {node {旋转式}
			child {node {华为}}
			child {node {小米}}
			child {node {Vivo}}
		};
		
	\end{tikzpicture}
 		
 
 	\newpage
 	\subsection{代码示例}
 	\subsubsection{电脑品牌信息}
 	\includegraphics[width=1.0\textwidth]{structModel/bridgeModel/commputerBrand-BridgeModel.pdf}
 
 	\subsubsection{电脑品牌信息2}
 	\includegraphics[width=1.0\textwidth]{structModel/bridgeModel/commputerBrand-BridgeModel2.pdf}
 	
 	 	\subsubsection{jdbc-Connection}
 	\includegraphics[width=1.0\textwidth]{structModel/bridgeModel/jdbc-BridgeModel.pdf}
 	
 	\subsubsection{config-4种配置}\label{lab:config4}
 	\begin{enumerate}
 		\item AbstractOperationAcquisitionData 抽象的数据操作,持有对SceneConfigInfo的引用,可以调用SceneConfigInfo下的相关的操作
 		\begin{itemize}
 			\item BasicProjectAcquisitionOperationData 基本/项目排放的config操作
 			\item ExpectationRealityAcquisitionOperationData 实际/期望的config 操作
 		\end{itemize}
 		
 		\item SceneConfigInfo	各自场景的接口
 		\begin{itemize}
 			\item ProjectEmissionConfigInfo 项目排放配置
 			\item ExpectEconomicBenefitConfigInfo 期望配置
 			\item RealEconomicBenefitConfigInfo 实际配置
 			\item BasicEmissionConfigInfo 基本配置
 		\end{itemize}
 	\end{enumerate}
 	\includegraphics[width=1.0\textwidth]{structModel/bridgeModel/config-BridgeMode.pdf}
 	\newpage
 	\subsection{其他说明}
 	

 	
 	\subsubsection{桥接模式公共操作放抽象类。单个操作放桥接的接口中是否合理}
 	
 	\ref{lab:config4}得出,在软件设计中，桥接模式（Bridge Pattern）旨在将抽象部分与实现部分分离，使它们可以独立变化。根据您的描述，这里是对该模式应用的一些建议：
 	\begin{enumerate}
 		\item  公共操作放在抽象类中：
 		\begin{itemize}
 			\item 合理。抽象类通常用于定义一个接口或一组接口的通用行为，这些行为对所有（或大多数）子类都是共通的。将公共操作放在抽象类中，可以确保所有遵循该抽象的实现都具备这些功能，同时遵循了面向对象设计中的“重复使用，而非重复编写”原则。
 		\end{itemize}
 		
 		\item 单个操作放在桥接的接口中：
 		\begin{itemize}
 			\item 这里可能需要澄清。桥接模式中的“桥接”通常是指通过一个接口（或抽象类）来连接抽象部分和实现部分，使得两者可以独立变化。如果“单个操作”指的是具体到某个实现细节的操作，那么它应该放在实现接口的具体类中，而不是接口本身。
 			\item 接口（或抽象类作为桥接接口）应当定义的是多个实现类可能共享的最抽象的行为定义，而不是具体的单个操作。具体的操作实现应该在实现了这个接口的各个具体类中完成，以保持接口的纯粹性和实现的灵活性。
 		\end{itemize}
 	\end{enumerate}
 	
 	总结来说，公共操作放在抽象类中是合理的，因为它促进了代码的复用和结构的清晰。而对于单个操作，应根据其具体性来决定放置位置：抽象的行为定义适合放在接口或抽象类中，而具体的操作实现则应归属到实现这些接口的具体类中。这样既保持了设计的灵活性，也遵循了桥接模式的核心思想。
 	
 	\newpage
 	\section{代理模式-proxy}
 	对一个对象进行访问控制的原因是只有在我们需要这个对象的时候才对他进行创建和初始化,比如在一个文档编辑器中,有些图形对象(如大型的光栅图像)的创建开销很大,但是打开文档需要很迅速,在打开文档时应避免一次性创建开销很大的对象,因为并非所有的对象在文档中都需要一次呈现,所以没有必要同时创建
 	
 	代理模式（Proxy Pattern）是一种结构型设计模式，它为另一个对象（称为“真实对象”或“被代理对象”）提供一个代理对象，并由代理对象控制对真实对象的访问。代理对象与真实对象对外提供的接口相同，因此在客户端看来两者是可以互换的。代理模式的主要目的包括但不限于以下几点：
 	
 	在使用动态代理的时候注意避免重载,有些代理需要清除的知道调用了哪个操作,重载运算符的方法,在这种情况下时行不通的
 	
 	\begin{enumerate}
 		\item 控制访问：通过代理对象可以添加访问控制，比如权限验证、记录日志等，在访问真实对象之前进行前置操作。
 		\item 延迟初始化：在真正需要使用真实对象的时候才初始化，减少资源消耗，比如懒加载。
 		\item 远程代理：为一个位于不同地址空间的对象提供局部代表，也就是分布式系统中的远程对象代理。
 		\item 保护隐私：隐藏真实对象的引用，防止直接访问，保证安全性。
 		\item 计算优化：缓存代理可以在多次请求中避免重复计算，提高性能。
 		\item 同步控制：在多线程环境下，代理对象可以管理并发访问，实现同步控制。
 	\end{enumerate}
 	
 	\newpage
 	代理模式的角色主要包括：
 	\begin{itemize}
 		\item 抽象主题（Subject）：声明了真实主题和代理主题共同的接口，以便在任何一方上调用。
 		\item 真实主题（Real Subject）：也称为被代理对象，包含了实际的业务逻辑。
 		\item 代理主题（Proxy）：实现了与真实主题相同的接口，通过持有对真实主题的引用，在必要时候调用真实主题的方法，并可能在其前后加入额外的操作。
 	\end{itemize}
 	
 	在实现上，代理模式通常有静态代理和动态代理两种形式：
 	\begin{itemize}
 		\item 静态代理：代理类在编译时就已经确定，代码中明确指定了代理类对哪个具体的真实主题进行代理。
 		\item 动态代理：代理类在运行时动态生成，如Java中的JDK动态代理或CGLIB动态代理，无需提前定义代理类，只要实现一个InvocationHandler接口或使用ASM等字节码操作库，就能根据传入的目标类生成对应的代理类。
 	\end{itemize}
 	
 	\newpage
 	
 	\subsection{静态代理-接口代理}
 	一类接口一个代理,不方便
 	
 	\includegraphics[width=1.0\textwidth]{structModel/proxy/interface-static-proxy.pdf}

 	
 	\newpage
 	\subsection{动态代理,接口代理}
 	基于接口的代理,需要实现InvocationHandler接口,reflect包下的proxy
 	
 	\includegraphics[width=1.0\textwidth]{structModel/proxy/jdk-dynamic.pdf}
 	
 	\newpage
		\subsubsection{远程代理}
 	远程代理是一种特殊的代理模式，它代表一个位于不同地址空间（如网络上的另一台计算机）的对象。当客户端与远程服务交互时，由于直接访问远程对象存在诸如网络延迟、数据传输成本、跨进程通信复杂性等问题，远程代理作为本地代理对象被创建并驻留在客户端。客户端通过调用远程代理的方法来执行操作，而远程代理负责封装网络通信细节，如协议转换、数据序列化与反序列化、远程方法调用等，以透明地将请求转发给远程服务器上的真实对象，并将远程对象的响应传递回客户端。这样，客户端无需关心远程交互的具体实现，只需与本地代理进行交互，就如同操作本地对象一样。
 	
 	InvocationHandler： 在Java中，java.lang.reflect.InvocationHandler 是一个接口，它是实现Java动态代理的关键组件之一。当使用Java标准库中的java.lang.reflect.Proxy 类来创建动态代理对象时，需要提供一个实现了 InvocationHandler 接口的类实例。这个接口定义了一个方法：
 	
 	实现 InvocationHandler 接口的类通常会根据 method 和 args 来决定如何处理方法调用。在远程代理场景中，invoke() 方法的实现可能会包括以下步骤：
 	
 	\begin{enumerate}
 		\item 封装请求：将方法调用的相关信息（如方法名、参数）打包成适合网络传输的数据结构或消息。
 		\item 网络通信：使用相应的通信框架（如RMI、HTTP、gRPC等）将封装好的请求发送到远程服务端。
 		\item 等待响应：阻塞等待服务端对请求的处理结果。
 		\item 处理响应：接收到服务端返回的结果后，可能需要进行反序列化等操作，将远程服务的响应还原为本地可处理的对象。
 		\item 返回结果：将处理后的结果作为 invoke() 方法的返回值返回给客户端。
 		
 	\end{enumerate}
 	总结来说，远程代理是代理模式的一种，用于解决客户端与远程服务之间的交互问题。InvocationHandler 接口则是Java动态代理机制中用于处理代理对象方法调用的核心接口，其invoke()方法的实现负责封装远程调用逻辑，使得客户端可以通过代理对象透明地与远程服务进行交互。
 	
 	\newpage
 	\subsubsection{虚代理}
 	以便在某些情况下延迟或控制对真实对象的访问。虚拟代理的主要目的是在必要时才创建或加载真实对象，从而优化性能、减少资源消耗，或者在真实对象不可用或尚未准备就绪时提供临时替代行为。以下是虚拟代理的一些关键特性：
 	\begin{enumerate}
 		\item 延迟初始化： 虚拟代理通常在真实对象的创建成本较高（例如初始化时间长、占用大量内存）的情况下使用。它可以在客户端首次请求时才创建真实对象，而不是在应用程序启动之初就立即创建。这样，只有当实际需要使用真实对象时，才付出创建的代价，从而避免了不必要的资源浪费。
 		\item 缓存或数据预取： 虚拟代理可以作为一个中间层，用于缓存真实对象的计算结果或数据。当客户端请求数据时，代理先检查缓存中是否存在所需结果。如果存在，直接返回缓存数据；否则，才委托给真实对象进行计算或从远程服务器加载数据，并在得到结果后将其存储在缓存中，供后续请求复用。
 		\item 资源控制与过滤： 虚拟代理可以控制对真实对象的访问权限，比如限制并发访问的数量，或者在访问前进行必要的权限检查。此外，它还可以对请求进行过滤，只允许符合特定条件的请求访问真实对象，例如仅当客户端满足一定的认证要求时才创建或访问真实对象。
 		\item 简化接口或提供额外功能： 虚拟代理可以为真实对象提供一个更简洁或更易于使用的接口，隐藏真实对象的复杂性。同时，它还可以在代理对象上增加额外的功能，如统计方法调用次数、记录访问日志、添加事务管理等，而无需修改真实对象的代码。
 		\item 占位符与进度指示： 当真实对象需要较长时间加载或生成（如大文件下载、复杂图像渲染等）时，虚拟代理可以作为临时占位符，先提供一个基本的、简化的视图，或者显示加载进度信息，直到真实对象完全可用时再替换为完整内容。
 		内容...
 	\end{enumerate}
 	
 	\newpage
 	\subsubsection{保护代理-鉴权}
 	保护代理是代理模式的一种变体，主要用于控制对目标对象的访问权限，对客户端的请求进行过滤或添加额外的访问控制逻辑。其主要目的包括：
 	\begin{enumerate}
 		\item 权限管理： 根据客户端的身份、角色、权限等级等信息，保护代理可以决定是否允许访问目标对象的方法，以及允许访问哪些方法。对于未经授权的请求，代理可以拒绝访问或抛出异常，从而保护目标对象免受非法或不合适的操作。
 		\item 资源访问控制： 对于共享资源，保护代理可以控制并发访问的数量，防止过多的客户端同时访问导致资源过度消耗或死锁。例如，数据库连接池代理可以限制同时打开的连接数，超过限制时返回错误或放入队列等待。
 		\item 日志记录与监控： 在客户端访问目标对象之前或之后，保护代理可以记录访问日志，包括访问时间、访问者、访问方法、参数及返回结果等信息，用于审计、故障排查或性能分析。此外，代理还可以监控目标对象的状态变化，触发告警或采取相应措施。
 		\item 输入验证与过滤： 保护代理可以对客户端传入的参数进行验证，确保它们符合预期的格式、范围或业务规则。对于不符合规则的请求，代理可以拒绝或修正参数后再转发给目标对象。这有助于提前发现并阻止潜在的错误或恶意攻击。
 		\item 事务管理： 在涉及事务操作的场景中，保护代理可以封装事务的开启、提交、回滚等操作，确保目标对象的方法在一个一致的事务上下文中执行。代理可以协调多个方法调用的事务边界，提供统一的事务管理接口。
 		\item 异常处理与恢复： 当目标对象抛出异常时，保护代理可以捕获这些异常，进行适当的处理（如记录错误日志、通知监控系统、尝试恢复操作等），然后向客户端返回一个友好的错误消息或异常包装对象，避免暴露内部实现细节。
 	\end{enumerate}
 	
 	在实现保护代理时，同样可以选择静态代理（编写特定代理类）或动态代理（如Java中的java.lang.reflect.Proxy和InvocationHandler接口）。代理类通常会实现与目标对象相同的接口，并在每个方法中添加上述访问控制逻辑
 	
 	以下是一个简单的保护代理示例，假设有一个银行账户类（BankAccount），保护代理（ProtectedBankAccountProxy）为其添加了密码验证逻辑：
 	
 	在这个例子中，ProtectedBankAccountProxy 类作为保护代理，实现了与BankAccount相同的接口，并在deposit()和withdraw()方法中添加了密码验证逻辑。只有当客户端提供的密码正确时，才会调用真实账户对象的方法，否则抛出异常。这样，保护代理有效地控制了对银行账户的访问权限，防止未经授权的访问。
 	\newpage
 	\subsubsection{智能指引-同步代理}
 	取代了简单的指针,在访问对象时,可以自动释放时执行一些附加操作,典型用途包括
 	
 	\begin{itemize}
 		\item 当指向实际对象的引用计数,这样当该对象没有引用时,可以自动释放它,
 		\item 当第一次引用一个持久对象时,将它装入内存
 		\item 在访问一个实际对象钱,检查是否已经锁定了它,以确保其他对象不会改变他
 	\end{itemize}
 	
 	\newpage
	\subsection{动态代理,cglib代理}
	接口,方法都可以实现代理,不需要接口, final或者static关键字修复的方法不可使用cglib代理
 	\includegraphics[width=1.0\textwidth]{structModel/proxy/cglib-proxy.pdf}


 
	
 	\newpage
 	\section{装饰者模式-decorator}
 	装饰者设计模式（Decorator Design Pattern）是一种结构型设计模式，它允许在运行时动态地给对象添加新的职责（行为或特性），同时保持原有的功能不变。装饰者模式通过引入装饰类来扩展对象的行为，而非通过修改原有类或者创建子类的方式来扩展功能。
 	
 	装饰者模式的角色包括：
 	\begin{enumerate}
 		\item Component（组件接口）：定义了一个对象的基本操作，是装饰者和被装饰对象的公共接口。
 		\item ConcreteComponent（具体组件）：实现了Component接口，是被装饰的具体对象。
 		\item Decorator（装饰者）：实现了Component接口，持有对Component对象的引用，装饰者的每个实例都包装着一个真实的Component对象。装饰者的主要任务是在执行Component原有操作的基础上，附加额外的操作。
 		\item ConcreteDecorator（具体装饰者）：是Decorator类的子类，实现了从Component接口继承下来的方法，并在这些方法中既可以调用被装饰对象的方法，又可以增加新的行为。
 	\end{enumerate}
 	
 	通过装饰者模式，我们可以灵活地向一个现有对象添加新功能，同时不会影响其他对象。这种方式相比于继承更加灵活，因为它可以在运行时决定要装饰哪些对象以及装饰多少次，而且不会导致类爆炸的问题。例如在咖啡店点餐系统中，基础咖啡是一个Component，然后可以添加糖、奶、香料等各种装饰者，形成各种口味的咖啡，每一种装饰者都是ConcreteDecorator，它们不仅提供基础咖啡的功能，还增加了各自特有的风味。
 	
 	

	\newpage
	\subsection{装饰者设计模式diagram实例}
	\subsubsection{咖啡}
	\includegraphics[width=1.0\textwidth]{structModel/decorator/office.pdf}
	
	
	\subsubsection{mybatis执行器}
	\includegraphics[width=1.0\textwidth]{structModel/decorator/mybatis.pdf}
	
 	\newpage
 	\section{享元模式-flyWeight}
 	享元模式（Flyweight Pattern）是一种结构型设计模式，主要用于减少大量细粒度对象的内存占用，提高系统的性能。它通过共享内部状态相同的部分对象，只在需要时创建不同的外部状态对象，从而大幅度减少系统中对象的数量，以节约内存资源。
 	
 	享元模式的角色包括：
 	\begin{enumerate}
 		\item Flyweight（享元类）：这是一个抽象类或者接口，它定义了共享的内容以及如何共享。享元类一般存储内部状态（不可变的共享部分）并提供一些方法来操作外部状态（可变的非共享部分）。
 		\item ConcreteFlyweight（具体享元类）：实现了享元类，存储共享的内部状态，并提供了具体的实现。对于共享的内部状态，所有具体享元对象都会共享同一份数据。
 		\item UnsharedConcreteFlyweight（非共享具体享元类）：如果有不能共享的状态，那么就需要定义非共享的具体享元类来存储这些状态。
 		\item FlyweightFactory（享元工厂类）：负责创建并管理享元对象，确保合理地共享和分配享元对象。当客户端请求一个享元对象时，工厂类首先检查是否存在相同的对象，如果存在就返回已经存在的对象，如果不存在则创建一个新的享元对象。
 	\end{enumerate}
 	
 	
 	例如，在字体渲染引擎中，可以使用享元模式来共享大量的小尺寸位图字符。每个字符（如A、B、C等）的内在形态（如笔画、轮廓等）是固定的，这部分内容可以共享；而每个字符的位置、颜色等则是可变的外部状态。通过享元工厂，我们可以只存储一份字符内在形态的信息，大大节省了内存资源。
 	
 	\newpage
 	\subsection{代码示例}
	\subsubsection{网站享元模式}
 	
	 	\includegraphics[width=1.0\textwidth]{structModel/flyWeight/flyWeight-website.pdf}
 	 	\subsubsection{jdk源码-Interger}
 	\includegraphics[width=1.0\textwidth]{structModel/flyWeight/flyWeight-Interger-IntegerCache.pdf}
 	\newpage
 	\section{外观模式-facade}
 	
 	外观模式（Facade Pattern）是一种结构型设计模式，其主要目的是为复杂的子系统提供一个简洁、统一的接口，从而降低外部模块与子系统间的耦合度。通过定义一个高层接口，使得客户端能够通过一个简单的接口调用一组相关的方法，而不需要了解系统内部的具体复杂性。
 	
 	外观模式的角色包括：
 	\begin{enumerate}
 		\item Facade（外观类）：为子系统中的一组接口提供一个统一的入口。它定义了一个更高级别的接口，使得子系统更容易使用。外观类中包含了对各个子系统的引用，并在此处协调和组织各子系统的操作顺序。
 		\item Subsystem Classes（子系统类）：这一系列类构成了完整子系统的内部结构，它们可以独立运作，但在外观类的协调下，可以更好地协作完成更高层次的功能。
 	\end{enumerate}
 	
 	举个例子，假设有一个复杂的家庭影院系统，包括投影仪、DVD播放器、音响等多个设备。如果不使用外观模式，用户需要分别启动并设置每一个设备才能看电影。但如果定义一个外观类“HomeTheaterFacade”，它就可以封装一系列操作，如startMovie()，这个方法内部可以依次开启并配置所有必要的设备，为用户提供了一个简单易用的接口，无需关心内部的复杂细节。
 
 	\newpage 
 	\subsubsection*{未使用Facde}\label{la:noFacde}
 	\begin{tikzpicture}\label{la:noFacde}
 		\node [circle,draw] (CC) {用户};
 		 
 		\node [circle,draw] (B) [right=of CC] {B};
 		\node [circle,draw] (C) [below=of B] {C};
 		\node [circle,draw] (D) [right=of B] {D};
 		\node [circle,draw] (E) [right=of C] {E};
 		
 		% \draw[arrow] (server1.south) -- node[left] {Link A} (server2.north);
 		% \draw[arrow] (A.north) -- node[left] link{AL} (B.north);
 
 		\draw[->]  (CC) -- (B);
 		\draw[->]  (CC) -- (E);
 		\draw[->]  (CC) -- (C);
 		\draw[-{>>[sep=2pt]}]  (CC) to [bend left=45]  (D);
 		
 	\end{tikzpicture}
 	
 	
 	\subsubsection*{使用Facde}\label{la:hasFacde}
 	\begin{tikzpicture}
 		\node [circle,draw] (CC) {用户};
 		\node [circle,draw] (A) [below=of CC] {A};
 		\node [circle,draw] (B) [right=of A] {B};
 		\node [circle,draw] (C) [below=of B] {C};
	 	\node [circle,draw] (D) [right=of B] {D};
	 	\node [circle,draw] (E) [right=of C] {E};
 
	 	% \draw[arrow] (server1.south) -- node[left] {Link A} (server2.north);
	 	% \draw[arrow] (A.north) -- node[left] link{AL} (B.north);
	 	\draw[->]  (CC) -- (A);
	 	\draw[->]  (A) -- (B);
	 	\draw[->]  (A) -- (E);
	 	\draw[->]  (A) -- (C);
	 	\draw[-{>>[sep=2pt]}]  (A) to [bend left=45]  (D);

  	\end{tikzpicture}

	\subsection{外观模式diagram实例}
	\subsubsection{电影}
	\includegraphics[width=1.0\textwidth]{structModel/facde/movice.pdf}
	\subsubsection{mybatis读取元数据}
	\includegraphics[width=1.0\textwidth]{structModel/facde/mybatis_ReflectorFactory_metaObject.pdf}
	
 	\newpage
 	\section{组合模式-composite}
 	组合模式（Composite Pattern）是一种结构型设计模式，它将对象组合成树形结构以表示“部分-整体”的层次关系，使得用户对单个对象和组合对象的使用具有一致性。组合模式的关键在于，它让客户代码能够忽略组合对象与单个对象的区别，统一地处理整个对象树中的所有对象。
 	
 	组合模式的角色包括：
 	\begin{enumerate}
 		\item Component（组件）：这是组合中的基本接口或抽象类，定义了所有组件共有的操作，这些操作可以是对对象本身的处理，也可以是对子组件的递归处理。所有的叶子节点和组合节点都要实现这个接口或继承这个抽象类。
 		\item Leaf（叶子节点）：代表那些没有子元素的简单对象，它实现了Component接口，并提供相应的业务操作。叶子节点没有子节点。
 		\item Composite（组合节点）：代表那些具有容器特性的对象，它同样实现了Component接口，并扩展了管理子组件的方法，如添加、删除子组件，遍历子组件等。同时，组合节点可以包含多个子节点（Component）。
 	\end{enumerate}
 	
 	
 	通过组合模式，客户端代码可以一致地处理单个对象和组合对象，简化了对对象树的操作。例如在文件系统中，文件夹（组合节点）和文件（叶子节点）都可以看作是Component，它们都有名称、大小等属性，并且都可以执行打开、删除等操作。这样，无论处理单个文件还是包含多个文件和子文件夹的文件夹，客户端代码都可以采用同样的方式进行操作。
 	
 	\subsection{组合模式diagram实例}
 	\subsubsection{组合模式-组织树}
	\includegraphics[width=1.0\textwidth]{structModel/combination/Combination-Tree.pdf}
 	\subsubsection{组合模式-Map}
	\includegraphics[width=1.0\textwidth]{structModel/combination/Combination-HashMap.pdf}
 	\newpage
 	\part{行为型结构模式}
 	
 	代码中的不同的行为,对象之间的交互
 	
 	% 行为型模式
 	\section{中介者模式-mediator}
 	承担了一个协调的职责,交警指挥十字路口/车祸现场的交通, 负责控制和协调一组对象间的交互
 	
 	中介者模式（Mediator Pattern）是一种行为设计模式，它定义了一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用，从而使其耦合度降低，使得系统变得更加易于维护和扩展。在中介者模式中，各个同事对象（Colleague）通过中介者（Mediator）进行通信，而不是互相直接调用对方的方法。
 	
 	中介者模式的角色包括：
 	\begin{enumerate}
 		\item  	Mediator（中介者）：定义一个接口，用于与各个同事对象进行交互。中介者对象集中了各同事对象之间的交互规则，它封装了同事对象之间的交互逻辑，使得各个同事对象只需关注自身的业务逻辑，而不需要了解其他同事对象的实现细节。
 		\item  ConcreteMediator（具体中介者）：实现了Mediator接口，具体定义了协调各同事对象之间交互的业务规则。它知道并持有同事对象的引用，负责管理和协调各同事对象之间的交互。
 		\item  Colleague（同事类）：定义了同事对象的接口，每个同事对象只知道中介者而不知道其他的同事对象。同事对象需要通过中介者对象来进行信息交换，而不是直接与其他同事对象通信。同事与同事之间互不感知
 		\item  ConcreteColleague（具体同事类）：实现了Colleague接口，是真正的业务对象，每个具体同事对象在需要与其他同事对象通信时，通过中介者对象来进行。对
 		
 		\item (特殊说明)同事向一个中介者对象发送和接收请求,中介者在各同事之间适当的转发请求已实现协作行为
 	\end{enumerate}

 	举个例子，假设在一个聊天室应用中，每个聊天参与者（具体同事类）并不直接和其他参与者通信，而是通过聊天室服务器（具体中介者）来发送和接收消息。这样，即使增加或删除聊天参与者，也不会直接影响到其他参与者的代码，极大地增强了系统的可维护性和扩展性。
 	
 	\subsection{适用性}
 	在以下情况下可以使用中介者模式
 	\begin{enumerate}
 		\item 一组对象已定义良好,但复杂的方式进行通信,产生的互相依赖关系的结构混乱且难以理解
 		\item 一个对象引用其他很多对象并且直接于这些对象通信,导致难以复用该对象
 		\item 想定制一个分部在多个类中的行为,而又不想生成太多的子类
 	\end{enumerate}
 	
 	\subsection{中介者模式的优缺点}
 	\begin{enumerate}
 		\item 减少了子类的生成 Mediator 中介者将原本分部于多个对象间的行为集中在一起,改变这些行为只需要生成Mediator 的子类即可, 这样各个Colleague 同事类可被复用; 如果同事间还有别的定制化的处理需求,可以扩展新的Mediator 
 		\item 将各个Colleague 解耦, Mediator 和各Colleague 间的松耦合,你可以独立的改变和复用各Colleague 类 和 Mediator 中介者类
 		\item 简化了对象协议 用Mediator中介者和Colleague 同事之间的一对多交互来代替多对多交互,一对多的关系更容易理解,维护和扩展
 		\item 对对象如何协作做了抽象 将中介作为一个独立的概念并将其封装在一个对象中,使你将注意力从对象的各自本身的行为转移到他们之间的交互上来,这有助于弄清楚一个系统中的对象时如何交互的
 		\item 是控制集中化 中介者模式将交互的复杂性变为了中介者的复杂性,因为中介者封装了协议,他可能变得比任何一个Colleague 都复杂,这可能使得中介者自身成为一个难于维护的庞然大物
 	\end{enumerate}
 	\newpage
 	\subsection{代码示例}
 	
 	\subsubsection{电影院-中介者模式}
 	\includegraphics[width=1.0\textwidth]{behaviorModel/mediatorModel/mediator-Movie.pdf}
 	
 	
 	\newpage
 	\subsection{相关模式}
 	\begin{enumerate}
 		\item Facade 外观模式是对一个对象子系统的抽象,从而提供了一个更为方便的接口,他的协议是单向的,即外观模式Facde 对象对这个子系统类提出请求, Mediator 中介者模式提供了各Colleague对象的协作行为,而且协议是多向的
 		\item Colleague 之间可使用Observer 观察者模式与Mediator 中介者通信
 	\end{enumerate}
 	\newpage
 	\section{模板方法模式-template类行为型模式}
 	是一种代码复用的基本技术,流程一致,细节不一致
 	模板方法模式（Template Method Pattern）是一种行为设计模式，它在一个抽象类中定义一个算法的骨架，但允许子类在不改变结构的前提下重写算法的某些步骤。这种模式创建了一个通用的过程模板，并将一些步骤推迟到子类中实现。
 	
 	在模板方法模式中，主要涉及以下角色：
 	
 	\begin{enumerate}
 		\item AbstractClass（抽象类）：定义了一个或多个抽象方法供子类实现，同时定义了一个模板方法（template method）。这个模板方法是一个具体方法，它会调用抽象方法和其他的操作，规定了算法的骨架。
 		\item ConcreteClass（具体子类）：继承自抽象类，实现抽象类中定义的抽象方法，完成算法中可变的具体步骤。每个具体子类都可以提供一个算法的特定实现。,实现了一个算法不变的部分,定义了公共的行为,方法名使用final关键字使用,避免被重写,造成逻辑上的问题
 		
 		\item 给模板方法加上前缀"-Do",如"DoCreateDocument","DoRead","DoDownLoad"
 		\item 这种结构有时被称为"好莱坞法则",即"别找我们,我们找你",这指的是一个父类调用子类的过程
 		
 		\begin{itemize}
			\item 原语操作(即抽象操作)
 			\item 具体的操作(ConcreteClass或对客户类的操作)
 			\item 具体的AbstractClass 操作,(即通常对子类有用的操作) final关键字修饰
 			\item 钩子操作,提供了缺省的行为,子类可以在必要时进行扩展,钩子操作在缺省情况下通常是空操作
 		\end{itemize}
 
 	\end{enumerate}
 	
 	例如，在制作饮料的过程中，抽象类可以是BeverageMaker，它定义了制作饮料的通用步骤，如加水、加糖、搅拌和加热等。其中，加热是固定步骤，而加水、加糖的具体量则由子类（如CoffeeMaker和TeaMaker）去实现。这样，尽管具体的饮料制作过程有所不同，但整体的流程是固定的，体现了模板方法模式的思想。
 	
 	模板方法模式的主要优点是可以封装不变部分，同时促进代码复用，降低子类之间的耦合度，简化代码结构。同时，它保证了算法的骨架不变，子类只需关注实现步骤的差异部分。
 	
 	
 	\subsection{适用性}
 	\begin{enumerate}
 		\item 一次性实现一个算法的不变部分,并将可变的行为留给子类实现
 		\item 各子类公共的行为应被提取出来并集中到一个公共父类中以避免代码重复,首先识别现有代码中的不同之处,并且将不同之处分离为新的操作,最后用一个调用新的操作的模板方法来替换不同的代码
 		\item 控制子类扩展,模板方法只在特定点调用钩子操作(空操作,预留的其他操作的接口),这样只允许在这些点进行扩展
 	\end{enumerate}
 	\newpage
 	
 	\subsection{代理案例示意图}
 	\subsubsection{豆浆制作}
 	不同的豆浆除了选择材料的不一致,其他都是一致的,即统一了算法,也提供了很大的灵活性,父类的末班方法确保了算法的结构保持不变,同时由于类提供了部分步骤的实现
 	
 	\includegraphics[width=1.0\textwidth]{behaviorModel/templateModel/soy-templateMethod.pdf}
 	
 	\newpage
 	
 	\subsection{相关模式}
 	Factory Method 常被模板方法调用,如在动机一节的例子中,DoCreateDocument就是一个Factory Method,他由模板方法OpenDocument调用
 	
 	strategy策略模式,模板方法模式使用继承来改变算法的一部分,Strategy 使用委托来改变整个算法
 	
 	\newpage
 	\section{策略模式-strategy-对象行为型模式}

 	别名 policy(政策)
 	
 	策略模式（Strategy Pattern）是一种行为设计模式，它定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。策略模式使得算法可以自由切换，也让算法能够在不影响客户端的情况下独立演化。
 	
 	在策略模式中，主要涉及以下角色：
 	
 	\begin{enumerate}
 		\item Strategy（策略接口/抽象类）：定义了一个公共的操作接口，这个接口中定义了所有支持的算法的公共方法。每个具体的策略类都需要实现这个接口。
 		\item ConcreteStrategy（具体策略类）：实现了策略接口，提供了具体的算法实现。在程序运行时，可以选择使用哪一个具体策略类的对象来执行相应的操作。
 		\item Context（上下文类）：维护了一个对策略对象的引用，用来调用具体策略类的方法。上下文类可以根据需要更改所使用的策略对象，以便在运行时选择不同的策略。
 	\end{enumerate}
 	
 	举例来说，在一个电商系统中，计算商品价格时可能会有不同的优惠策略，如原价销售、打折销售、买一赠一等。这时可以定义一个DiscountStrategy策略接口，然后有OriginalPriceStrategy、DiscountedPriceStrategy和\-
 	BuyOneGetOneFreeStrategy等具体策略类。上下文类ShoppingCart中可以根据用户的购买情况选择合适的策略进行计算。这样，系统就可以方便地在运行时动态切换不同的定价策略，而无需修改核心业务逻辑。
 	
 	\subsection{适用性}
 	在以下情况下使用Strategy模式
 	\begin{enumerate}
 		\item 许多相关的类仅仅是行为有异,"策略"提供了一种用多个行为中的一个行为来配置一个类的方法
 		\item 需要使用一个算法的不同变体,例如你可能会定义一些反应不同空间/时间来权衡的算法,当这些变体实现为一个算法的类层次时,可以使用策略模式
 		\item 算法使用客户不应该知道数据,可使用策略模式已避免暴露复杂的,与算法相关的数据结构,
 		\item 一个类定义了多种行为,并且这些行为在这个类的奥做中以多个条件语句的形式出现,将相关的条件分支移入他们各自的Strategy 类中以替代这些条件语句
 	\end{enumerate}

	\newpage
	\subsection{代码示例}
	
	\subsubsection{各种鸭子的不同行为}
	
	\includegraphics[width=1.0\textwidth]{behaviorModel/strageModel/strategyModel-duck-FlyBehavior.png}
	
	
	\subsubsection{不同的折扣计算}
	
	\includegraphics[width=1.0\textwidth]{behaviorModel/strageModel/stategyModel-FixedAmountDiscount.pdf}

 	\newpage
 	\subsection{相关模式}
 	\begin{enumerate}
 		\item Flyweight 享元模式,Strategy对象经常是很好的轻量级对象
 	\end{enumerate}
 	\newpage
 	\section{观察者模式-observer}
 	
 	 	依赖(dependent) ,发布-订阅(pulish-subscribe): 当一个对象的状态发生改变时,所有依赖他的对象都得到通知并自动被更新
 	 	
 	观察者模式（Observer Pattern）是一种行为设计模式，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一主题对象（Subject）的状态变化。当主题对象的状态发生改变时，所有依赖于它的观察者对象都会得到通知并自动更新。
 	
 	在观察者模式中，主要涉及以下角色：
 	
 	\begin{enumerate}
 		
 		\item Subject（主题/被观察者）：这是所有观察者所订阅的核心对象，它提供了注册和移除观察者的方法，以及通知所有观察者的方法。主题对象存储了观察者对象的一个集合，并在自身状态发生变化时调用通知方法。
 		\item ConcreteSubject（具体主题）：是Subject接口的实现，通常包含一些特定业务逻辑，会在状态改变时触发通知机制。
 		\item Observer（观察者）：定义了一个接口，该接口声明了更新方法，当主题对象状态改变时，这个方法会被调用。
 		\item ConcreteObserver（具体观察者）：实现了Observer接口，它保存了一个对Subject对象的引用，并在接收到主题对象的通知后，执行相应的更新操作。
 		
 		\item (非必须) 当目标和观察者之间的依赖关系特别复杂时,可能需要一个维护这些关系的对象,我们称这样的对象为更改管理器(changeManager). 他的母的是尽量检查观察者反应其目标的状态变化所需的工作量,例如当一个操作涉及对几个互相依赖的目标进行改动,就必须保证尽在所有目标都已更改完毕后,才一次性的通知他们的观察者,而不是每个目标都通知它的观察者,类似于目标之间也存在依赖性,在几个目标完成之后,才通知他们的观察者,changeManager有以下几个责任
 		
 		\begin{enumerate}
 			\item 他将一个目标映射到他的观察者并提供一个接口来维护这个映射,这就不需要由目标来维护对其观察者的引用,反之亦然
 			\item 他定义一个特定的更新策略,
 			\item 他根据一个目标的请求,他更新所欲依赖于这个目标的观察者
 		\end{enumerate}
 	\end{enumerate}
 	
 	在实际应用中，观察者模式常用于事件驱动编程，比如GUI框架中的按钮点击事件处理、订阅-发布系统中的消息推送等场景。它有助于降低对象之间的耦合度，使得系统更加灵活，易于扩展。通过观察者模式，每当主题状态改变时，无需手动逐个调用依赖对象的方法，而是通过主题统一发布变更通知，观察者们自行响应。
 	
 	\subsection{适用性}
 	在以下情况下可以使用观察者模式
 	\begin{enumerate}
 		\item 一个抽象模型有两个方面,其中一个依赖于另一方面,将这两者封装在独立的对象中,以使他们可
 		以各自独立的改变和复用
 		\item 对一个对象的改变需要同时的改变其他对象,而不知道具体有多少对象有待改变
 		\item 一个对象必须通知其他对象,而他又不能假定其他对象是谁,换言之,你不希望这些对象时紧密耦合的
 	\end{enumerate}
 	
 	\subsection{优缺点}
 	\begin{enumerate}
 		\item 目标和观察者的解耦 一个目标所知道的仅仅是它有一系列的观察者,每个都符合抽象的Observer列的简单接口,目标不知道任何一个观察着属于哪一个具体的类,这样目标和观察者之间的耦合是抽象的最小和
 		
 		\item 支持广播通信 区别于通常的通信,目标的发送通知不需要指定他的接收者,通知被自动的广播给所有已向该目标对象对象登记的对象,目标对象并不关心到底有多少对象对自己感兴趣,他的唯一责任就是通知它的各个观察者,这给了你在任何时刻增加或者删除观察者的自由,处理还是忽略一个通知取决于观察者
 		\item 意外的更新 由于一个观察者不知道其他观察者的存在,他可能对改变目标的最终代价一无所知,在目标上一个看似无害的操作,可能会引起以系统对观察者以及依赖于这个观察者的对象更新,此外,如果依赖准则的定义或维护不挡,常常会引起错误的更新
 	\end{enumerate}
 	 	\newpage
 	\subsection{代码示例}
 	
 	\subsubsection{天气预报通知}
 	\includegraphics[width=1.0\textwidth]{behaviorModel/observerModel/weatherData_observer.pdf}
 	
 	\newpage
 	\subsection{相关模式}
 	\begin{enumerate}
 		\item Mediator 中介者模式,通过封装更复杂的更新语义,ChangeManager 充当目标和观察者之间的中介者
 		
 		\item  Singleton : 单例模式,ChangeManager 可使用Singleton 模式来保证它是唯一的并且是可全局访问的
 	\end{enumerate}
 	\newpage
 	\section{访问者模式-visitor}
 	作用于某对象结构中的各元素的操作,它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作
 	
 	访问者模式（Visitor Pattern）是一种行为设计模式，它允许在不改变现有类层次结构的情况下，为类层次结构中的对象增加新的操作。访问者模式通过将算法分离到单独的类中，使得可以通过在运行时传递不同的访问者对象给元素集合，来对元素集合执行不同的操作。
 	
 	在访问者模式中，主要涉及以下角色：
 	\begin{enumerate}
 		\item Visitor（访问者）：这是一个接口或抽象类，它声明了一系列访问操作，每个操作对应一个元素类。在这里，元素类是指构成对象结构的类。
 		\item ConcreteVisitor（具体访问者）：实现了Visitor接口，为每个元素类实现了相应的方法，即对元素类的不同访问操作。
 		\item Element（元素）：这是对象结构中能接受访问者的对象所对应的接口或抽象类，声明了一个接受访问者的accept()方法。
 		\item ConcreteElement（具体元素）：实现了Element接口，实现了accept()方法，该方法接受访问者对象作为参数，并调用访问者对象的相应方法，以使访问者访问该元素。
 		\item ObjectStructure（对象结构）：能够存储元素对象并允许访问者访问这些元素，通常提供了迭代访问元素的方法，使得访问者可以访问到每一个元素。List<Node>或者List<Element>
 	\end{enumerate}
 	
 	举例来说，在一个文档编辑软件中，元素可以是段落、图片、表格等组成文档的各种对象，访问者可以是格式转换器、统计工具等需要对这些元素进行操作的类。通过访问者模式，我们可以轻松地为文档添加新的处理方式（新的访问者类），而不需要修改文档元素类本身。
 	
 	
 	\newpage
 	\subsection{代理实例}
 	\subsubsection{评分系统}
 	\includegraphics[width=1.0\textwidth]{behaviorModel/vistorModel/vistor-comment-Level.pdf}
 	
 	
 	
 	\newpage
 	\section{命令模式-command-对象行为型模式}
 		别名: action (动作), 事务(transaction),
 		
 		命令模式（Command Pattern）是一种行为设计模式，它将请求封装为一个对象，使得可以用不同的请求、队列或者日志来参数化其他对象。命令模式也支持撤销操作，同时命令对象还可以在调用者和接收者之间起到解耦的作用。
 		
 		在命令模式中，涉及的主要角色包括：
 		\begin{enumerate}
 			\item Command（命令接口）：声明执行命令的接口，通常包含 execute() 方法以及其他可能的方法，如 undo()（撤销操作）和 redo()（重做操作）。
 			\item ConcreteCommand（具体命令类）：实现了 Command 接口，存储了接收者对象的引用，使用set或者构造来注入这个值, 并定义了如何调用接收者对象  Receiver（的方法来完成请求。每一个具体命令类对应一个具体的动作。
 			\item Receiver（接收者类）：知道如何实施和执行与命令相关的操作。任何类都可能成为一个接收者，只要它提供了命令所需的业务操作。
 			\item Invoker（调用者类）：持有命令对象并对命令对象发出请求，通常调用命令对象的 execute() 方法来执行命令。调用者并不知道命令是如何被执行的，只知道调用命令对象的执行方法。
 			\item client创建一个具体命令对象并设置他的接收者, 调用者发出了一个指令,具体谁执行,是由调用者调用command但是调用者对于哪一个command来执行是不可感知的,就是调用者不知道command子类的身份, 而command下的execte将调用该 Receiver的一个或者多个操作, 来执行的
 		\end{enumerate}
 		
 		通过命令模式，我们可以：
 		\begin{itemize}
 			\item 将请求封装为对象，使得可以使用标准的方法来传递请求、排队请求、记录请求日志，以及支持可撤销的操作。
 			\item 支持可撤销(undo)/重做操作(redo)。
 			\item 解耦调用者与接收者，使得调用者不必了解接收者接口的具体实现。
 		\end{itemize}
 

	\subsection{适用性}
	当有如下需求时可使用Command模式
	\begin{enumerate}
		\item 回调函数,所谓回调函数是指函数现在某处注册,而他将在稍后某个需要的时间被调用先在某出注册,而他将在稍后的某个需要的时候被回调使用,Command 模式就是回调机制的一个面向对象的产品
		\item 不同的时刻指定,排列和执行请求,一个Command对象可以有一个与初始请求无关的生存期,如果一个请求的接收者可用一种与地址空间无关的方式表达,那么就可将负责该请求的命令对象传送给另一个不同的进程,并在哪里实现该请求
		\item 支持取消操作,Command的Execute操作可在实施操作前将状态存储起来,在取消操作时这个状态用来消除该操作的影响,Command接口必须添加一个Unexecute操作,该操作取消上次Execute调用的效果,执行的命令被存储在一个历史列表中,可通过向后和向前遍历这一列表并分别调用Unexecute和Execute来实现重数不限的"撤销"和"重做",若应用只支持一次撤销操作,那么只需要存储最近一次被执行的命令;若要支持多级的撤销和重做,就需要有一个已被执行命令的历史列表,该列表的最大长度决定了撤销和重做的级数,历史列表存储了已被执行的命令序列,向后遍历该列表并逆向执行(reserve-executing)命令是撤销,向前遍历并执行命令是重新执行他们
 		\item 执行修改日志,回滚与重新执行
		\item  执行事务的信息系统中很常见,一个事务封装了对数据的一组变动
	\end{enumerate}

	\subsection{效果}
	Command模式有以下的效果
	\begin{enumerate}
		\item commnad将调用操作的对象与知道如何实现该操作的对象解耦
		\item command是头等对象,可像其他对象一样被操纵和扩展
		\item 你可将多个命令装配成一个组合命令,例如前面描述的MacroCommand类,一般来说,组合命令是 Composite 模式的一个实例
		\item 增加新的Commnad很容易,因为这无须改变已有的类
	\end{enumerate}
	
	\newpage
	\subsection{代理实例}
	\subsubsection{智能家居}
	UnCommand 或者NoCommand对于简化操作,有帮助,可以简化对于空的判断
	
	目前这里我们onCommand 一个对象,offCommand 一个对象
	
	\includegraphics[width=1.0\textwidth]{behaviorModel/commandModel/LightReceive-Command.pdf}
 
 	\newpage
 	\subsection{其他模式}
 	Composite(4.3) 组合模式,可用来实现宏命令,用于执行一系列预定义的命令或操作
 	
 	Memento 备忘录,可用来保持某个状态,命令用这一个状态来取消他的效果
 	
 	Prototype 在被放入历史列表前必须被拷贝的命令起到一种原型的作用
 	\newpage
 	\section{状态者模式-state}
 	状态者模式（State Pattern）是一种行为设计模式，它允许一个对象在其内部状态改变时改变其行为。这种模式将对象的状态与行为解耦，使得对象在不同的状态下表现出不同的行为，而无需使用大量的条件分支语句来判断状态。
 	
 	在状态者模式中，涉及的主要角色包括：
 	
 	\begin{enumerate}
 		\item Context（环境类）：环境类拥有一个状态对象，它可以调用状态对象的方法来改变其内部状态。环境类把请求委托给当前状态对象处理，并在状态变化时切换到新的状态对象。
 		\item State（状态接口或抽象类）：定义了所有具体状态类需要实现的接口或抽象方法。这些方法通常是与环境类进行交互的方法，表明在某个状态下可以执行哪些操作。
 		\item ConcreteState（具体状态类）：实现了State接口或继承自抽象状态类，每个具体状态类对应一个具体的状态，定义了在该状态下对象如何响应请求。
 	\end{enumerate}
 	
 	举例来说，ATM取款机就是一个很好的状态者模式的应用实例。ATM机可以根据卡的状态（如正常、挂失、冻结等）来执行不同的操作。这里的Context就是ATM机，State是银行卡状态接口，而ConcreteState则可能是正常状态、挂失状态和冻结状态等具体类，每个具体状态类都决定了在该状态下ATM机可以执行什么操作，如取款、查询余额或拒绝交易等。
 	
 	使用状态者模式的好处在于：
 	\begin{itemize}
 		\item 把复杂的条件分支逻辑分散到了各个状态类中，提高了代码的可读性和可维护性。
 		\item 新增或修改状态变得相对容易，只需要添加或修改具体状态类即可，遵循开闭原则。
 		\item 状态的变化逻辑更加清晰，状态间的转换过程更加直观。
 	\end{itemize}
 	\subsection{适用性}
 	在以下的两种青口下均可使用State模式
 	\begin{enumerate}
 		\item 一个对象的行为取决于他的状态,并且它必须在运行时根据状态来改变他的行为
 		\item 一个操作中含有庞大的多分支的条件语句,且这些分支依赖于该对象的状态,这个状态通常用一个或多个枚举常量表示,通常,有多个操作包含这一相同的条件结构, State模式将每一个分支放入一个独立的类中,这使得你可以根据对象自身的情况将对象的状态作为一个对象,这一对象可以不依赖于其他对象二独立变化
 	\end{enumerate}
 	
 	\subsection{协作}
 	\begin{enumerate}
 		\item Context 将于状态相关的请求委托给当前的ConcreateState对象来处理
 		\item Context 可将自身作为一个参数传递给处理该请求的状态对象,这使得状态对象在必要时可访问Context 对象
 		\item Context 是客户使用的主要接口,客户可用状态对象来配置一个Context,一旦一个Context配置完成,他的客户不在需要直接于状态对象来打交道
 		\item Context 或者Concretestate 子类都可决定哪个状态是另外一个的后继者,以及实在何种条件下进行切换
 	\end{enumerate}
	\newpage
	\subsection{代码示例}
	\subsubsection{抽奖状态}
	\includegraphics[width=1.0\textwidth]{behaviorModel/stateModel/state-Lottery-state.pdf}
 	
 	\newpage
 	\subsection{其他模式}
 	\begin{enumerate}
 		\item  Flyweight 享元模式解释了何时以及这样共享状态对象
 		\item  状态对象通常都是单例模式Singleton
 	\end{enumerate}
 	\newpage
 	\section{责任链模式-chain}
 	为了避免责任链中出现无限的循环,一定要确保请求最终能够被某个处理者处理,或者在链的终端设置一个默认的处理者来终结请求.
 	
 	使多个对象都有机会处理请求,曹伟避免请求的发送者和接收者之间的解耦关系,并不明确的知道谁是最终的处理对象,该请求有一个隐式的接受者,当客户提交一个请求时,请求沿链调用直至有一个ConcreteHandler 对象负责处理它
 	
 	责任链模式（Chain of Responsibility Pattern）是一种行为设计模式，用于创建对象链，其中每个对象都有处理请求的方法。当请求沿着链传递时，链上的每个对象都有机会对其进行处理，直至请求被处理完或者到达链的末尾。这种模式允许将请求的发送者和接收者解耦，使得多个对象有机会处理同一个请求，同时也使得新增或移除处理请求的对象变得容易。
 	
 	在责任链模式中，主要有以下几个角色：
 	\begin{enumerate}
 		\item Handler（处理器接口或抽象类）：如helperHandler 定义了处理请求的接口，其中包含了指向下一个处理器的引用，这样处理器对象就可以形成一个链式结构。同时，它还定义了处理请求的方法。
 		\item ConcreteHandler（具体处理器类）：实现了Handler接口，每个具体处理器类负责处理一个或多个请求。它检查请求是否适合自己的处理条件，如果合适，则处理请求，否则将请求转发给链上的下一个处理器。
 		\item Request（请求对象）：封装了需要处理的信息，请求对象可以在链上传递。 建议处理的责任链需要是一个环形的,这种最合适,否则就必须从第一个节点开始处理
 	\end{enumerate}
 	
 	使用责任链模式的典型场景包括：
 	\begin{itemize}
 		\item 日志记录系统，不同级别的日志会被不同的处理器处理。
 		\item 许可权系统，请求经过一系列的权限检查，每个检查环节处理自己负责的权限范围。
 		\item GUI事件处理，如按键事件、鼠标事件等，会按照一定的顺序传递给一系列监听器处理。
 	\end{itemize}
 	
 	\subsection{适用性}
	在以下条件适用Chain of Responsibility模式
	\begin{enumerate}
		\item 有多个对象可以处理一个请求,那个对象处理该请求运行时自动确定
		\item 你想在不明确指定接收者的情况下,想多个对象中的换一个提交一个请求
		\item 可处理一个请求的对象集合应被动态指定
	\end{enumerate}
	
	
	\subsection{优点与缺点}
	Chain of Responsibility模式的优点与缺点
	\begin{enumerate}
		\item 降低了耦合度, 该模式使得一个对象无须知道是其他哪一个对象处理其请求.对象仅需要知道该请求会被"正确"处理,接收者和发送者都没有对方的明确信息,且链中的对象不需要知道链中的结构,结果是职责链可简化对象的相互连接,他们进需要保持一个指向其后继者的引用,而不需要保持他所有的候选接收者的引用
		
		\item 增强了对对象指派职责的灵活性,当对象中分派职责时,职责链给你更多的灵活性,你尅通过在运行时,对盖帘进行动态的增加或改变处理的一个请求的那些职责,你可以将这种机制与静态的特例化处理对象的集成机制结合起来使用
		
		\item 不保证被接受 既然一个请求没有明确的接收者,那么就不能保证它一定会被处理 该请求可能一直到链的末端都得不到处理,一个请求也可能因该链没有被正确配置而得不到处理
	\end{enumerate}
 	\newpage
 	\subsection{代码示例}
 
 	\subsubsection{申购流程审批}
 	每个人都有机会处理
 	
 	\includegraphics[width=1.0\textwidth]{behaviorModel/chainOfResponsibilityModel/chainOfResponsibility-approval.pdf}	
 	\newpage
 	\subsection{其他模式}
 	\begin{enumerate}
 		\item 职责链通常与Composite 组合模式一起使用,这种情况相爱,一个构件的父构件可作为他的后继
 	\end{enumerate}
 	\newpage
 	\section{备忘录模式-memento}
 	恢复到先前的状态,类似于git
 	
 	备忘录模式（Memento Pattern）是一种行为型设计模式，别名token,它主要用于在不破坏封装性的前提下捕获和恢复对象的内部状态。在该模式中，涉及到的主要角色包括：
 	
 	\begin{enumerate}
 		\item Originator（原始对象/发起人）：这是具有内部状态的复杂对象，它可以创建一个备忘录对象来捕获当前的内部状态，并且可以使用备忘录对象来恢复先前的内部状态。
 		\item Memento（备忘录）：这是一个辅助类，它存储了发起人对象的内部状态，但是对外部世界而言，其内部细节通常是隐藏的。备忘录仅向发起人暴露必要的方法来检索其保存的状态。
 		\item Caretaker（负责人/管理者）：负责保存和恢复发起人的备忘录对象，但它不能访问备忘录对象内部的详细状态信息。它只是作为一个安全的容器来保存备忘录，以便在需要的时候可以将其提供给发起人。
 	\end{enumerate}
 	
 	
 	使用备忘录模式的场景通常是在需要撤销操作或者恢复到历史状态的场合，例如文本编辑器的撤销功能、游戏存档/读档功能等。通过这种方式，发起人可以在不影响其封装性的同时，保持内部状态的灵活性和可恢复性。
 	
 	\subsection{适用性}
 	\begin{enumerate}
 		\item 必须保存一个对象在某个时刻的(部分状态),这样以后需要时它才能恢复到先前的状态
 		\item 如果一个接口让其他对象直接得到这些状态,将会暴露对象的实现细节并破坏对象的封装性
 	\end{enumerate}
 	\newpage
 	\subsection{代码示例}
 	\subsubsection{怪物状态恢复}
 	
 	\includegraphics[width=1.0\textwidth]{behaviorModel/mementoModel/monster-momento-Caretaker.pdf}
 	\newpage
 	\subsection{相关模式}
 	\begin{enumerate}
 		\item Command 命令模式,可使用备忘录来为可撤销的操作维护状态
 		\item Iterator 迭代器模式,备忘录模式可用于迭代
 	\end{enumerate}
 	\newpage
 	\section{迭代器模式-iterator-对象行为型模式}
 	别名cursor
 	迭代器模式（Iterator Pattern）是一种行为设计模式，它提供了一种方法顺序访问一个聚合对象（如集合、数组或其他容器）的元素，而无需暴露该对象的底层表示。迭代器模式将遍历集合的责任与集合本身的实现分离开来，使得客户端代码可以通过统一的接口访问不同类型的集合，并且无需关心集合的具体实现。
 	
 	多态迭代的概念:迭代器和列表(dataList)是耦合在一起的,而且客户对象必须知道遍历的是一个列表还是其他的聚合的结构,最好能有一种办法使得不需要改变客户端代码即可改变聚合类,可以通过迭代器的概念推广到多态迭代来实现这个目标
 	
 	在迭代器模式中，主要包括以下角色：
 	
 	\begin{enumerate}
	 	\item Iterator（迭代器接口）：定义了访问和遍历元素所需的方法，如hasNext()（判断是否有下一个元素）、next()（返回下一个元素）等。
	 	\item ConcreteIterator（具体迭代器类）：实现了迭代器接口，维护一个指向当前集合内部结构的指针（称为游标），并在遍历时管理这个指针的位置。
	 	\item Aggregate（聚合接口/容器）：定义了创建迭代器对象的方法，通常有一个createIterator()方法来返回一个迭代器实例。appendItem(),removeItem()
	 	\item ConcreteAggregate（具体聚合类）：实现了聚合接口，存储元素集合，并确保具体迭代器类能够正确访问和遍历这些元素。
	 	\item  (非必须)空迭代器是一个退化的迭代器,有助于处理边界条件,根据定义,NullIterator总是完成遍历的,更容易遍历树形结构的集合,在遍历过程中的每一个节点,都可向当前的元素请求遍历其各个子节点的迭代器,该聚合元素将返回一个具体的迭代器,但叶节点元素返回NullIterator的一个实例,这就使我们可用一种统一的方式实现在整个结构上的遍历
 	\end{enumerate}
 	
 	通过迭代器模式，可以轻松地遍历各种类型的集合，同时避免暴露集合内部的数据结构。这样既简化了客户端代码，降低了耦合度，也为集合提供了更大的灵活性，可以随时新增或改变集合的实现，而不会影响到使用迭代器遍历集合的客户端代码。
 	
 	以下情况可使用迭代器模式,为外部提供了统一的接口,遍历的api
 	\begin{enumerate}
 		\item 访问一个聚合对象内容,而无需暴露他的内部表示
 		\item 支持对聚合对象的多种遍历方式:如,前序/后序/中序/正序/逆序
 		\item 为遍历不同的聚合结构提供一个统一的接口(即支持多态迭代)
 	\end{enumerate}
 	
 	\newpage
 	\subsubsection{不同的院系结构的迭代}
 	
 	\includegraphics[width=1.0\textwidth]{behaviorModel/iterorModel/iterator-Department.pdf}
 	\newpage
 	\subsubsection{相关模式}
 	\begin{enumerate}
 		\item Composite 迭代器常被应用到向组合这样的递归结构上
 		\item Factory Method 多态迭代器靠Factory Method 来实例化适当的迭代器子类
 		\item Memento 备忘录模式,常与迭代器模式一起使用,迭代器可使用memento来捕获一个迭代的状态,迭代器在其内部存储memento备忘录
 	\end{enumerate}
 	
 	\newpage
 	
 	\section{解释器模式}
	解释器模式（Interpreter Pattern）)是一种行为设计模式，
 	给定一个语言,定义他的文法中的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子,如果一种特定类型的问题发生的频率足够高,那么就值得将该问题的各个示例表述为一个简单语言中的句子,这样就可以构建一个解释器,该解释器通过解释这些句子来解决该问题
 	
 	例如搜索匹配一个模式的字符串是一个常见的问题。正则表示式是描述字符串模式的换一个标准语言。与其为每一个模式都构造一个特定的算法，不如使用一种通用的搜索算法来解释执行一个正则表达式，该正则表达式定义了待匹配字符串的集合
 	
 	在解释器模式中，主要包括以下角色：
 	\begin{enumerate}
 		\item 抽象表达式（Abstract Expression）：
 		类型：接口或抽象类。
 		责任：定义所有解释器共有的操作，通常包括一个interpret()方法，这是解释操作的核心。
 		\item 终结符表达式（Terminal Expression）：
 		类型：实现了抽象表达式的类。
 		责任：处理文法中的终结符，即文法的基本构建块，通常是简单的符号或常量。它们是最简单的解释任务，直接映射到特定的解释操作。
 		\item 非终结符表达式（Non-terminal Expression）：
 		类型：实现了抽象表达式的类。
 		责任：处理文法中的非终结符，通常是文法中的运算符或逻辑结构。非终结符表达式可以包含一个或多个子表达式，它们组合子表达式以完成更复杂的解释任务。
 		\item 上下文（Context）：
 		类型：通常是一个类。
 		责任：提供解释过程中所需的环境信息，比如全局变量、状态或服务。上下文对象在解释过程中被传递给interpret()方法，使得解释器可以访问必要的背景信息。
 		\item 客户端（Client）：
 		类型：使用解释器的代码。
 		责任：构建抽象语法树（AST），并使用解释器来解释这个树。客户端通常会创建解释器实例，构建表达式树，并调用interpret()方法来执行解释。
 		
 	
 	\end{enumerate}
 	
 		解释器模式通常用于实现简单的语言或表达式解释，例如配置文件、计算表达式等。通过构建一个表达式树，解释器模式可以将结构化的输入转换成对应的输出。
 		
 
 	\subsection{适用性}
 	当有一个语言需要解释执行，并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。而当存在以下情况时该模式效果最好：
 	
 	\begin{enumerate}
 		\item 文法简单，对于复杂的文法，文法的类层次变得庞大而无法管理，此时语法分析程序生成器这样的工具是更好的选择。他们无序抽象构建语法树即可解释表达式，这样可以节省空间而且还能节省时间
 		
 		\item 效率不是关键问题。最高效的解释器通常不是通过直接解释语法分析树实现的，而是首先将他们转换成另一种形式。例如正则表达式通常被转换成状态机。但即使在这种情况下，转换器也可用解释器模式来实现，该模式仍是可用的
 	\end{enumerate}
 	
 	\newpage
 	\subsection{代码实例}
 	\subsubsection{加减法解释器}
 	\includegraphics[width=1.0\textwidth]{behaviorModel/interpretModel/interpret-Add-Sub-SymbolExpression}
 	\newpage
 	
 	\subsection{其他模式}
 	\begin{enumerate}
	 	\item Composite组合模式，抽象语法树时一个组合模式的实例
	 	\item Flyweight 享元模式，说明了如何在抽象语法树中共享终结符
	 	\item Iterator 迭代器模式，解释器可用一个迭代器遍历该结构
	 	\item Visitor 访问者模式，可用来维护一个类中维护抽象语法树中该语法树的行为
 	\end{enumerate}
 	
 	
\end{document}
